Hi Alexey,
No you didn't miss anything that should really be 100.0 or the switch input should be renamed to be labled X75. I suspect 100X was a bit too fast for one particular machine so the step size was reduced a bit. The selector inputs should probably be named SpeedA, SpeedB, SpeedC, SpeedD. Then all that has to match is the software factors and the lables on the selector switch.
Regards
TK
| Group: DynoMotion |
Message: 4116 |
From: Alexey Volkov |
Date: 2/27/2012 |
| Subject: Re: MPG example |
Thanks, Tom
Just some more question:
1. Standard g-code does not have the tool definitions except the offsets, so, as I got it, I have to prepare the g-code in the CAM system according to the tools I using and the actual mill setup. (The g-code is optimized and specified to the mill).
Why KmotionCNC has tool configuration? Just for someone who do not use CAM's and does the g-code programming manually? What is better way? (I mean do give the CAM to decide the tool path or to use KmotionCNC trajectory planner to optimize it for KFlop?)
2. Is it any "open" information on KFlop - PC communication protocol, so I can create custom control software (mostly to change the platform, I would prefer to do not use Windows based system). Did anybody try to port KMotionCNC to Linux, Mac OSX? As far as KMotion is just GUI, it should not be so difficult.
Best regards, Alexey On Mon, Feb 27, 2012 at 2:04 PM, Tom Kerekes <tk@...> wrote:
Hi Alexey,
No you didn't miss anything that should really be 100.0 or the switch input should be renamed to be labled X75. I suspect 100X was a bit too fast for one particular machine so the step size was reduced a bit. The selector inputs should probably be named SpeedA, SpeedB, SpeedC, SpeedD. Then all that has to match is the software factors and the lables on the selector switch.
Regards
TK
| Group: DynoMotion |
Message: 4117 |
From: Tom Kerekes |
Date: 2/27/2012 |
| Subject: Re: MPG example |
Hi Alexey,
Regarding:
#1 - I'm not a machinist and I'm not sure I understand your question. But the tool table is not really for any optimization. I think the basic idea is that GCode can be generated and then if a tool breaks or needs to be changed a new tool can be installed with a slightly different diameter and length and then the same GCode can still be used.
#2 - Yes the PC-KFLOP communication protocol is open. All the communication between the PC and KFLOP consists of ASCII Console Script Commands. You can send raw Console commands directly to KFLOP to control everything. But to operate in this mode you must do most everything yourself - Trajectory Planning, buffer management, etc... We have C++ libraries that run on the PC that operate on a higher level and allow you to just specify GCode to execute, or a Coordinated Motion Path you would like, and the libraries will handle all the Trajectory Planning and buffer management for you. These C++ libraries are all open as well. Unfortunately they contain some Microsoft Library References (MFC, CString, etc...) which make them incompatible with other platforms.
We use an FTDI USB device on our board. FTDI provides USB Drivers for many platforms including Linux. They also offer Virtual Com Port Drivers which makes it easy to have any application that can talk to a serial port send Console commands to KFLOP. There are Users who use KFLOP under Linux in this manner.
We have also found that our Applications and libraries run in Linux under Wine with the proper FTDI Driver loaded. Even Mach3 runs in Wine under Linux with KFLOP. There are a few quirks on connecting and diconnecting the device, and some minor GUI issues that would need to be resolved to make a releasable product, but running GCode, Jogging, Status, and so forth all seems to work.
Regards
TK
| Group: DynoMotion |
Message: 4118 |
From: Alexey Volkov |
Date: 2/27/2012 |
| Subject: Re: MPG example |
Thanks a lot, Tom!
So, generally speaking, you use standard FTDI driver to simulate the COM port and talk to the KFLOP directly. Where I can find the information regarding the ASCII console commands and open source C++ libraries you mention above?
I am not a professional programmer but I have done some programming, PC and embedded systems, hope I would eventually figure out how all that stuff works. Meanwhile, I would try to use VM with the KmotionCNC, thanks for the suggestions.
By the way, did anybody tried to combine EMC2 with your board?
Best regards, Alexey On Mon, Feb 27, 2012 at 3:05 PM, Tom Kerekes <tk@...> wrote:
Hi Alexey,
Regarding:
#1 - I'm not a machinist and I'm not sure I understand your question. But the tool table is not really for any optimization. I think the basic idea is that GCode can be generated and then if a tool breaks or needs to be changed a new tool can be installed with a slightly different diameter and length and then the same GCode can still be used.
#2 - Yes the PC-KFLOP communication protocol is open. All the communication between the PC and KFLOP consists of ASCII Console Script Commands. You can send raw Console commands directly to KFLOP to control everything. But to operate in this mode you must do most everything yourself - Trajectory Planning, buffer management, etc... We have C++ libraries that run on the PC that operate on a higher level and allow you to just specify GCode to execute, or a Coordinated Motion Path you would like, and the libraries will handle all the Trajectory Planning and buffer management for you. These C++ libraries are all open as well. Unfortunately they contain some Microsoft Library References (MFC, CString, etc...) which make them incompatible with other platforms.
We use an FTDI USB device on our board. FTDI provides USB Drivers for many platforms including Linux. They also offer Virtual Com Port Drivers which makes it easy to have any application that can talk to a serial port send Console commands to KFLOP. There are Users who use KFLOP under Linux in this manner.
We have also found that our Applications and libraries run in Linux under Wine with the proper FTDI Driver loaded. Even Mach3 runs in Wine under Linux with KFLOP. There are a few quirks on connecting and diconnecting the device, and some minor GUI issues that would need to be resolved to make a releasable product, but running GCode, Jogging, Status, and so forth all seems to work.
Regards
TK
| Group: DynoMotion |
Message: 4119 |
From: Tom Kerekes |
Date: 2/27/2012 |
| Subject: Re: MPG example |
Hi Alexey,
Yes in certain Applications, Languages, Platforms it is easy to send strings to serial devices, so in those cases it makes it easy to send simple commands to KFLOP.
The Console Commands are described here:
The overview of the C++ libraries is shown here:
Some of the Library functions are described here (but mainly you will need to look at the examples):
The .NET wrapper library probably has the best description of the library's capabilities:
(note: you will likely need to save this file, right click properties, select "unblock", to open this file.
Regarding EMC2: its not really clear how much that would make sense. The main design goal of EMC2 is to do the real-time control in the PC. The main design goal with KFLOP is to remove all the real-time control from the PC.
Regards
TK
| Group: DynoMotion |
Message: 4120 |
From: Alexey Volkov |
Date: 2/27/2012 |
| Subject: Re: MPG example |
Thanks for the links, Tom
Regarding the EMC: it does make sence to have G-Code interpreter and GUI platform independent and USB board like K-Flop as a motion control board, IMHO. Or at least to have KMotionCNC as cross-platform application, if possible. Otherwise the real price of the KFlop board goes up for the price of the OS you have to buy.
KFlop is already in the top "hobby segment" price range, compared to cheap solutions like Mach3 + LPT (Slow and legacy) or Smoothstepper (have died already?). Ideally, it would be nice to have a standalone system able to get the g-code from any available source directly or from the flash memory card.
Did anybody tried to transfer the g-code interpreter and the trajectory planner into the Kflop flash memory and run it internally, using the usb as a g-code feed only?
Best regards,
Alexey
On Mon, Feb 27, 2012 at 3:55 PM, Tom Kerekes <tk@...> wrote:
Hi Alexey,
Yes in certain Applications, Languages, Platforms it is easy to send strings to serial devices, so in those cases it makes it easy to send simple commands to KFLOP.
The Console Commands are described here:
The overview of the C++ libraries is shown here:
Some of the Library functions are described here (but mainly you will need to look at the examples):
The .NET wrapper library probably has the best description of the library's capabilities:
(note: you will likely need to save this file, right click properties, select "unblock", to open this file.
Regarding EMC2: its not really clear how much that would make sense. The main design goal of EMC2 is to do the real-time control in the PC. The main design goal with KFLOP is to remove all the real-time control from the PC.
Regards
TK
| Group: DynoMotion |
Message: 4121 |
From: Tom Kerekes |
Date: 2/27/2012 |
| Subject: Re: MPG example |
Hi Alexey,
Yes it would be great to have KMotionCNC as a cross platform application.
I think KMotionCNC+KFLOP+MSWindows is actually a lower cost solution compared to Mach3+SS+MSWindows.
Regards
TK
| Group: DynoMotion |
Message: 4122 |
From: Brad Murry |
Date: 2/27/2012 |
| Subject: Re: MPG example |
I am a Microsoft junkie for sure, but a cross platform DynoMotion API sounds very interesting. Especially with an HTML5 GUI linked to it with websockets for near-native performance. -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Monday, February 27, 2012 5:35 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] MPG example Yes it would be great to have KMotionCNC as a cross platform application. I think KMotionCNC+KFLOP+MSWindows is actually a lower cost solution compared to Mach3+SS+MSWindows. Thanks for the links, Tom Regarding the EMC: it does make sence to have G-Code interpreter and GUI platform independent and USB board like K-Flop as a motion control board, IMHO. Or at least to have KMotionCNC as cross-platform application, if possible. Otherwise the real price of the KFlop board goes up for the price of the OS you have to buy. KFlop is already in the top "hobby segment" price range, compared to cheap solutions like Mach3 + LPT (Slow and legacy) or Smoothstepper (have died already?). Ideally, it would be nice to have a standalone system able to get the g-code from any available source directly or from the flash memory card. Did anybody tried to transfer the g-code interpreter and the trajectory planner into the Kflop flash memory and run it internally, using the usb as a g-code feed only? On Mon, Feb 27, 2012 at 3:55 PM, Tom Kerekes <tk@...> wrote: Yes in certain Applications, Languages, Platforms it is easy to send strings to serial devices, so in those cases it makes it easy to send simple commands to KFLOP. The Console Commands are described here: The overview of the C++ libraries is shown here: Some of the Library functions are described here (but mainly you will need to look at the examples): The .NET wrapper library probably has the best description of the library's capabilities: (note: you will likely need to save this file, right click properties, select "unblock", to open this file. Regarding EMC2: its not really clear how much that would make sense. The main design goal of EMC2 is to do the real-time control in the PC. The main design goal with KFLOP is to remove all the real-time control from the PC. Sent: Monday, February 27, 2012 3:18 PM
Subject: Re: [DynoMotion] MPG example
Thanks a lot, Tom! So, generally speaking, you use standard FTDI driver to simulate the COM port and talk to the KFLOP directly. Where I can find the information regarding the ASCII console commands and open source C++ libraries you mention above?
I am not a professional programmer but I have done some programming, PC and embedded systems, hope I would eventually figure out how all that stuff works. Meanwhile, I would try to use VM with the KmotionCNC, thanks for the suggestions. By the way, did anybody tried to combine EMC2 with your board? Alexey On Mon, Feb 27, 2012 at 3:05 PM, Tom Kerekes <tk@...> wrote: #1 - I'm not a machinist and I'm not sure I understand your question. But the tool table is not really for any optimization. I think the basic idea is that GCode can be generated and then if a tool breaks or needs to be changed a new tool can be installed with a slightly different diameter and length and then the same GCode can still be used. #2 - Yes the PC-KFLOP communication protocol is open. All the communication between the PC and KFLOP consists of ASCII Console Script Commands. You can send raw Console commands directly to KFLOP to control everything. But to operate in this mode you must do most everything yourself - Trajectory Planning, buffer management, etc... We have C++ libraries that run on the PC that operate on a higher level and allow you to just specify GCode to execute, or a Coordinated Motion Path you would like, and the libraries will handle all the Trajectory Planning and buffer management for you. These C++ libraries are all open as well. Unfortunately they contain some Microsoft Library References (MFC, CString, etc...) which make them incompatible with other platforms. We use an FTDI USB device on our board. FTDI provides USB Drivers for many platforms including Linux. They also offer Virtual Com Port Drivers which makes it easy to have any application that can talk to a serial port send Console commands to KFLOP. There are Users who use KFLOP under Linux in this manner. We have also found that our Applications and libraries run in Linux under Wine with the proper FTDI Driver loaded. Even Mach3 runs in Wine under Linux with KFLOP. There are a few quirks on connecting and diconnecting the device, and some minor GUI issues that would need to be resolved to make a releasable product, but running GCode, Jogging, Status, and so forth all seems to work. Thanks, Tom 1. Standard g-code does not have the tool definitions except the offsets, so, as I got it, I have to prepare the g-code in the CAM system according to the tools I using and the actual mill setup. (The g-code is optimized and specified to the mill). Why KmotionCNC has tool configuration? Just for someone who do not use CAM's and does the g-code programming manually? What is better way? (I mean do give the CAM to decide the tool path or to use KmotionCNC trajectory planner to optimize it for KFlop?) 2. Is it any "open" information on KFlop - PC communication protocol, so I can create custom control software (mostly to change the platform, I would prefer to do not use Windows based system). Did anybody try to port KMotionCNC to Linux, Mac OSX? As far as KMotion is just GUI, it should not be so difficult.
Best regards, Alexey On Mon, Feb 27, 2012 at 2:04 PM, Tom Kerekes <tk@...> wrote: No you didn't miss anything that should really be 100.0 or the switch input should be renamed to be labled X75. I suspect 100X was a bit too fast for one particular machine so the step size was reduced a bit. The selector inputs should probably be named SpeedA, SpeedB, SpeedC, SpeedD. Then all that has to match is the software factors and the lables on the selector switch. Hello
I am new to the kflop board.
Going to retrofit the mill using one and would like to have MPG's installed to be able to use machine as manual till I have got figured out all the tricks related to g-code and cnc machining.
I have been looking at the C examples for the MPG.
Just one, probably stupid question:
Why the coefficient for X1 is 1.0, for X10 is 10.0 but for X100 is 75.0?
Did I miss something?
Best regards,
Alexey |
|
| Group: DynoMotion |
Message: 4125 |
From: Alexey Volkov |
Date: 2/27/2012 |
| Subject: Re: MPG example |
I would more look in Java direction for GUI, as a true cross-platform solution.
Best regards, Alexey On Mon, Feb 27, 2012 at 5:15 PM, Brad Murry <bradodarb@...> wrote:
I am a Microsoft junkie for sure, but a cross platform DynoMotion API sounds very interesting. Especially with an HTML5 GUI linked to it with websockets for near-native performance.
-Brad Murry
Yes it would be great to have KMotionCNC as a cross platform application.
I think KMotionCNC+KFLOP+MSWindows is actually a lower cost solution compared to Mach3+SS+MSWindows.
Thanks for the links, Tom Regarding the EMC: it does make sence to have G-Code interpreter and GUI platform independent and USB board like K-Flop as a motion control board, IMHO.
Or at least to have KMotionCNC as cross-platform application, if possible. Otherwise the real price of the KFlop board goes up for the price of the OS you have to buy.
KFlop is already in the top "hobby segment" price range, compared to cheap solutions like Mach3 + LPT (Slow and legacy) or Smoothstepper (have died already?).
Ideally, it would be nice to have a standalone system able to get the g-code from any available source directly or from the flash memory card.
Did anybody tried to transfer the g-code interpreter and the trajectory planner into the Kflop flash memory and run it internally, using the usb as a g-code feed only?
On Mon, Feb 27, 2012 at 3:55 PM, Tom Kerekes <tk@...> wrote:
Yes in certain Applications, Languages, Platforms it is easy to send strings to serial devices, so in those cases it makes it easy to send simple commands to KFLOP.
The Console Commands are described here:
The overview of the C++ libraries is shown here:
Some of the Library functions are described here (but mainly you will need to look at the examples):
The .NET wrapper library probably has the best description of the library's capabilities:
(note: you will likely need to save this file, right click properties, select "unblock", to open this file.
Regarding EMC2: its not really clear how much that would make sense. The main design goal of EMC2 is to do the real-time control in the PC. The main design goal with KFLOP is to remove all the real-time control from the PC.
Sent: Monday, February 27, 2012 3:18 PM
Subject: Re: [DynoMotion] MPG example
Thanks a lot, Tom! So, generally speaking, you use standard FTDI driver to simulate the COM port and talk to the KFLOP directly.
Where I can find the information regarding the ASCII console commands and open source C++ libraries you mention above?
I am not a professional programmer but I have done some programming, PC and embedded systems, hope I would eventually figure out how all that stuff works.
Meanwhile, I would try to use VM with the KmotionCNC, thanks for the suggestions. By the way, did anybody tried to combine EMC2 with your board? Alexey
On Mon, Feb 27, 2012 at 3:05 PM, Tom Kerekes <tk@...> wrote:
#1 - I'm not a machinist and I'm not sure I understand your question. But the tool table is not really for any optimization. I think the basic idea is that GCode can be generated and then if a tool breaks or needs to be changed a new tool can be installed with a slightly different diameter and length and then the same GCode can still be used.
#2 - Yes the PC-KFLOP communication protocol is open. All the communication between the PC and KFLOP consists of ASCII Console Script Commands. You can send raw Console commands directly to KFLOP to control everything. But to operate in this mode you must do most everything yourself - Trajectory Planning, buffer management, etc... We have C++ libraries that run on the PC that operate on a higher level and allow you to just specify GCode to execute, or a Coordinated Motion Path you would like, and the libraries will handle all the Trajectory Planning and buffer management for you. These C++ libraries are all open as well. Unfortunately they contain some Microsoft Library References (MFC, CString, etc...) which make them incompatible with other platforms.
We use an FTDI USB device on our board. FTDI provides USB Drivers for many platforms including Linux. They also offer Virtual Com Port Drivers which makes it easy to have any application that can talk to a serial port send Console commands to KFLOP. There are Users who use KFLOP under Linux in this manner.
We have also found that our Applications and libraries run in Linux under Wine with the proper FTDI Driver loaded. Even Mach3 runs in Wine under Linux with KFLOP. There are a few quirks on connecting and diconnecting the device, and some minor GUI issues that would need to be resolved to make a releasable product, but running GCode, Jogging, Status, and so forth all seems to work.
Thanks, Tom 1. Standard g-code does not have the tool definitions except the offsets, so, as I got it, I have to prepare the g-code in the CAM system according to the tools I using and the actual mill setup. (The g-code is optimized and specified to the mill).
Why KmotionCNC has tool configuration? Just for someone who do not use CAM's and does the g-code programming manually? What is better way? (I mean do give the CAM to decide the tool path or to use KmotionCNC trajectory planner to optimize it for KFlop?)
2. Is it any "open" information on KFlop - PC communication protocol, so I can create custom control software (mostly to change the platform, I would prefer to do not use Windows based system). Did anybody try to port KMotionCNC to Linux, Mac OSX? As far as KMotion is just GUI, it should not be so difficult.
Best regards, Alexey On Mon, Feb 27, 2012 at 2:04 PM, Tom Kerekes <tk@...> wrote:
No you didn't miss anything that should really be 100.0 or the switch input should be renamed to be labled X75. I suspect 100X was a bit too fast for one particular machine so the step size was reduced a bit. The selector inputs should probably be named SpeedA, SpeedB, SpeedC, SpeedD. Then all that has to match is the software factors and the lables on the selector switch.
Hello
I am new to the kflop board.
Going to retrofit the mill using one and would like to have MPG's installed to be able to use machine as manual till I have got figured out all the tricks related to g-code and cnc machining.
I have been looking at the C examples for the MPG.
Just one, probably stupid question:
Why the coefficient for X1 is 1.0, for X10 is 10.0 but for X100 is 75.0?
Did I miss something?
Best regards,
Alexey
|
|
| Group: DynoMotion |
Message: 4126 |
From: Brad Murry |
Date: 2/27/2012 |
| Subject: Re: MPG example |
Java in and of itself is not a GUI tool. I’d also argue that you cannot get any more ubiquitous than HTML for a GUI as it is used on everything from PC’s/mobile devices and even toasters. ;) C++ seems like the right tool for the cross platform job to me, but any port would be really cool. Plus there are several suitable GUI toolkits for java(netbeans, etc…) so I’m sure it would work out well. -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Alexey Volkov
Sent: Monday, February 27, 2012 8:28 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] MPG example I would more look in Java direction for GUI, as a true cross-platform solution. Alexey On Mon, Feb 27, 2012 at 5:15 PM, Brad Murry <bradodarb@...> wrote: I am a Microsoft junkie for sure, but a cross platform DynoMotion API sounds very interesting. Especially with an HTML5 GUI linked to it with websockets for near-native performance. -Brad Murry Yes it would be great to have KMotionCNC as a cross platform application. I think KMotionCNC+KFLOP+MSWindows is actually a lower cost solution compared to Mach3+SS+MSWindows. Thanks for the links, Tom Regarding the EMC: it does make sence to have G-Code interpreter and GUI platform independent and USB board like K-Flop as a motion control board, IMHO. Or at least to have KMotionCNC as cross-platform application, if possible. Otherwise the real price of the KFlop board goes up for the price of the OS you have to buy. KFlop is already in the top "hobby segment" price range, compared to cheap solutions like Mach3 + LPT (Slow and legacy) or Smoothstepper (have died already?). Ideally, it would be nice to have a standalone system able to get the g-code from any available source directly or from the flash memory card. Did anybody tried to transfer the g-code interpreter and the trajectory planner into the Kflop flash memory and run it internally, using the usb as a g-code feed only? On Mon, Feb 27, 2012 at 3:55 PM, Tom Kerekes <tk@...> wrote: Yes in certain Applications, Languages, Platforms it is easy to send strings to serial devices, so in those cases it makes it easy to send simple commands to KFLOP. The Console Commands are described here: The overview of the C++ libraries is shown here: Some of the Library functions are described here (but mainly you will need to look at the examples): The .NET wrapper library probably has the best description of the library's capabilities: (note: you will likely need to save this file, right click properties, select "unblock", to open this file. Regarding EMC2: its not really clear how much that would make sense. The main design goal of EMC2 is to do the real-time control in the PC. The main design goal with KFLOP is to remove all the real-time control from the PC. Sent: Monday, February 27, 2012 3:18 PM
Subject: Re: [DynoMotion] MPG example
Thanks a lot, Tom! So, generally speaking, you use standard FTDI driver to simulate the COM port and talk to the KFLOP directly. Where I can find the information regarding the ASCII console commands and open source C++ libraries you mention above?
I am not a professional programmer but I have done some programming, PC and embedded systems, hope I would eventually figure out how all that stuff works. Meanwhile, I would try to use VM with the KmotionCNC, thanks for the suggestions. By the way, did anybody tried to combine EMC2 with your board? Alexey On Mon, Feb 27, 2012 at 3:05 PM, Tom Kerekes <tk@...> wrote: #1 - I'm not a machinist and I'm not sure I understand your question. But the tool table is not really for any optimization. I think the basic idea is that GCode can be generated and then if a tool breaks or needs to be changed a new tool can be installed with a slightly different diameter and length and then the same GCode can still be used. #2 - Yes the PC-KFLOP communication protocol is open. All the communication between the PC and KFLOP consists of ASCII Console Script Commands. You can send raw Console commands directly to KFLOP to control everything. But to operate in this mode you must do most everything yourself - Trajectory Planning, buffer management, etc... We have C++ libraries that run on the PC that operate on a higher level and allow you to just specify GCode to execute, or a Coordinated Motion Path you would like, and the libraries will handle all the Trajectory Planning and buffer management for you. These C++ libraries are all open as well. Unfortunately they contain some Microsoft Library References (MFC, CString, etc...) which make them incompatible with other platforms. We use an FTDI USB device on our board. FTDI provides USB Drivers for many platforms including Linux. They also offer Virtual Com Port Drivers which makes it easy to have any application that can talk to a serial port send Console commands to KFLOP. There are Users who use KFLOP under Linux in this manner. We have also found that our Applications and libraries run in Linux under Wine with the proper FTDI Driver loaded. Even Mach3 runs in Wine under Linux with KFLOP. There are a few quirks on connecting and diconnecting the device, and some minor GUI issues that would need to be resolved to make a releasable product, but running GCode, Jogging, Status, and so forth all seems to work. Thanks, Tom 1. Standard g-code does not have the tool definitions except the offsets, so, as I got it, I have to prepare the g-code in the CAM system according to the tools I using and the actual mill setup. (The g-code is optimized and specified to the mill). Why KmotionCNC has tool configuration? Just for someone who do not use CAM's and does the g-code programming manually? What is better way? (I mean do give the CAM to decide the tool path or to use KmotionCNC trajectory planner to optimize it for KFlop?) 2. Is it any "open" information on KFlop - PC communication protocol, so I can create custom control software (mostly to change the platform, I would prefer to do not use Windows based system). Did anybody try to port KMotionCNC to Linux, Mac OSX? As far as KMotion is just GUI, it should not be so difficult.
Best regards, Alexey On Mon, Feb 27, 2012 at 2:04 PM, Tom Kerekes <tk@...> wrote: No you didn't miss anything that should really be 100.0 or the switch input should be renamed to be labled X75. I suspect 100X was a bit too fast for one particular machine so the step size was reduced a bit. The selector inputs should probably be named SpeedA, SpeedB, SpeedC, SpeedD. Then all that has to match is the software factors and the lables on the selector switch. Hello
I am new to the kflop board.
Going to retrofit the mill using one and would like to have MPG's installed to be able to use machine as manual till I have got figured out all the tricks related to g-code and cnc machining.
I have been looking at the C examples for the MPG.
Just one, probably stupid question:
Why the coefficient for X1 is 1.0, for X10 is 10.0 but for X100 is 75.0?
Did I miss something?
Best regards,
Alexey |
|
| Group: DynoMotion |
Message: 4675 |
From: par.hansson80 |
Date: 4/26/2012 |
| Subject: Re: MPG example |
I like how you guys think. I'm on the same track here.
Currently I'm working on a Java based product that is supposed to replace the KMotionCNC software. The software will be an eclipse based products enabling others to write their own plugins for whatever they need for their machines.
My progress so far is that the GCodeInterpreter has been ported to execute on Mac OS X compiled as a native shared library. It is compiled and linked with g++ so I don't se any problem with linux ports.
The ftd2xxj project (a JNI interface for ft2dxx native drivers) enables the java program to communicate with my KFLOP.
The GCodeInterpreter is currently only sending the commands to console. But I'm not far away from hooking it up with my Java program that will send the commands to the KFLOP.
The plan is to make my own wrapper for the ftd2xx drivers that will communicating with sockets. That way the application using the drivers can be used by software written in any language. In my case Java.
Future plans is to make a KFLOP server that runs on a Raspberry PI (if possible). Then it actually might be possible to use HTML as GUI and connect to the server with web sockets.
Regards Pär Hansson
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
>
>
> Java in and of itself is not a GUI tool. I'd also argue that you cannot
> get any more ubiquitous than HTML for a GUI as it is used on everything from
> PC's/mobile devices and even toasters. ;)
>
>
>
> C++ seems like the right tool for the cross platform job to me, but any port
> would be really cool.
>
>
>
> Plus there are several suitable GUI toolkits for java(netbeans, etc.) so I'm
> sure it would work out well.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of Alexey Volkov
> Sent: Monday, February 27, 2012 8:28 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> I would more look in Java direction for GUI, as a true cross-platform
> solution.
>
>
>
> Best regards,
>
> Alexey
>
> On Mon, Feb 27, 2012 at 5:15 PM, Brad Murry <bradodarb@...> wrote:
>
>
>
>
>
> I am a Microsoft junkie for sure, but a cross platform DynoMotion API
> sounds very interesting. Especially with an HTML5 GUI linked to it with
> websockets for near-native performance.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of Tom Kerekes
> Sent: Monday, February 27, 2012 5:35 PM
> To: DynoMotion@yahoogroups.com
>
>
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Hi Alexey,
>
>
>
> Yes it would be great to have KMotionCNC as a cross platform application.
>
>
>
> I think KMotionCNC+KFLOP+MSWindows is actually a lower cost solution
> compared to Mach3+SS+MSWindows.
>
>
>
> Regards
>
> TK
>
>
>
> From: Alexey Volkov <erry321@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 27, 2012 4:10 PM
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Thanks for the links, Tom
>
>
>
> Regarding the EMC: it does make sence to have G-Code interpreter and GUI
> platform independent and USB board like K-Flop as a motion control board,
> IMHO.
>
> Or at least to have KMotionCNC as cross-platform application, if possible.
> Otherwise the real price of the KFlop board goes up for the price of the OS
> you have to buy.
>
> KFlop is already in the top "hobby segment" price range, compared to cheap
> solutions like Mach3 + LPT (Slow and legacy) or Smoothstepper (have died
> already?).
>
> Ideally, it would be nice to have a standalone system able to get the g-code
> from any available source directly or from the flash memory card.
>
> Did anybody tried to transfer the g-code interpreter and the trajectory
> planner into the Kflop flash memory and run it internally, using the usb as
> a g-code feed only?
>
>
>
> Best regards,
>
> Alexey
>
>
>
>
>
> On Mon, Feb 27, 2012 at 3:55 PM, Tom Kerekes <tk@...> wrote:
>
>
>
> Hi Alexey,
>
>
>
> Yes in certain Applications, Languages, Platforms it is easy to send strings
> to serial devices, so in those cases it makes it easy to send simple
> commands to KFLOP.
>
>
>
> The Console Commands are described here:
>
>
>
> http://www.dynomotion.com/Help/CmdsCategory.htm
>
>
>
> The overview of the C++ libraries is shown here:
>
>
>
> http://www.dynomotion.com/Help/LibrariesFlowDiagram.PNG
>
>
>
> Some of the Library functions are described here (but mainly you will need
> to look at the examples):
>
>
>
> http://www.dynomotion.com/Help/KMotionDLLDriver/KMotionDLL.htm
>
>
>
> The .NET wrapper library probably has the best description of the library's
> capabilities:
>
>
>
> http://www.dynomotion.com/KMotion_dotNet/Docs/Help/KMotion.Net.chm
>
> (note: you will likely need to save this file, right click properties,
> select "unblock", to open this file.
>
>
>
>
>
>
>
> Regarding EMC2: its not really clear how much that would make sense. The
> main design goal of EMC2 is to do the real-time control in the PC. The main
> design goal with KFLOP is to remove all the real-time control from the PC.
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
> From: Alexey Volkov <erry321@...>
> To: DynoMotion@yahoogroups.com
>
> Sent: Monday, February 27, 2012 3:18 PM
>
>
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Thanks a lot, Tom!
>
>
>
> So, generally speaking, you use standard FTDI driver to simulate the COM
> port and talk to the KFLOP directly.
>
> Where I can find the information regarding the ASCII console commands and
> open source C++ libraries you mention above?
> I am not a professional programmer but I have done some programming, PC and
> embedded systems, hope I would eventually figure out how all that stuff
> works.
>
> Meanwhile, I would try to use VM with the KmotionCNC, thanks for the
> suggestions.
>
>
>
> By the way, did anybody tried to combine EMC2 with your board?
>
>
>
> Best regards,
>
> Alexey
>
> On Mon, Feb 27, 2012 at 3:05 PM, Tom Kerekes <tk@...> wrote:
>
>
>
> Hi Alexey,
>
>
>
> Regarding:
>
>
>
> #1 - I'm not a machinist and I'm not sure I understand your question. But
> the tool table is not really for any optimization. I think the basic idea
> is that GCode can be generated and then if a tool breaks or needs to be
> changed a new tool can be installed with a slightly different diameter and
> length and then the same GCode can still be used.
>
>
>
> #2 - Yes the PC-KFLOP communication protocol is open. All the communication
> between the PC and KFLOP consists of ASCII Console Script Commands. You can
> send raw Console commands directly to KFLOP to control everything. But to
> operate in this mode you must do most everything yourself - Trajectory
> Planning, buffer management, etc... We have C++ libraries that run on the
> PC that operate on a higher level and allow you to just specify GCode to
> execute, or a Coordinated Motion Path you would like, and the libraries will
> handle all the Trajectory Planning and buffer management for you. These C++
> libraries are all open as well. Unfortunately they contain some Microsoft
> Library References (MFC, CString, etc...) which make them incompatible with
> other platforms.
>
>
>
> We use an FTDI USB device on our board. FTDI provides USB Drivers for many
> platforms including Linux. They also offer Virtual Com Port Drivers which
> makes it easy to have any application that can talk to a serial port send
> Console commands to KFLOP. There are Users who use KFLOP under Linux in
> this manner.
>
>
>
> We have also found that our Applications and libraries run in Linux under
> Wine with the proper FTDI Driver loaded. Even Mach3 runs in Wine under
> Linux with KFLOP. There are a few quirks on connecting and diconnecting the
> device, and some minor GUI issues that would need to be resolved to make a
> releasable product, but running GCode, Jogging, Status, and so forth all
> seems to work.
>
>
>
> Regards
>
> TK
>
>
>
> From: Alexey Volkov <erry321@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 27, 2012 2:22 PM
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Thanks, Tom
>
>
>
> Just some more question:
>
>
>
> 1. Standard g-code does not have the tool definitions except the offsets,
> so, as I got it, I have to prepare the g-code in the CAM system according to
> the tools I using and the actual mill setup. (The g-code is optimized and
> specified to the mill).
>
> Why KmotionCNC has tool configuration? Just for someone who do not use CAM's
> and does the g-code programming manually? What is better way? (I mean do
> give the CAM to decide the tool path or to use KmotionCNC trajectory planner
> to optimize it for KFlop?)
>
> 2. Is it any "open" information on KFlop - PC communication protocol, so I
> can create custom control software (mostly to change the platform, I would
> prefer to do not use Windows based system). Did anybody try to port
> KMotionCNC to Linux, Mac OSX? As far as KMotion is just GUI, it should not
> be so difficult.
>
> Best regards,
>
> Alexey
>
> On Mon, Feb 27, 2012 at 2:04 PM, Tom Kerekes <tk@...> wrote:
>
>
>
> Hi Alexey,
>
>
>
> No you didn't miss anything that should really be 100.0 or the switch input
> should be renamed to be labled X75. I suspect 100X was a bit too fast for
> one particular machine so the step size was reduced a bit. The selector
> inputs should probably be named SpeedA, SpeedB, SpeedC, SpeedD. Then all
> that has to match is the software factors and the lables on the selector
> switch.
>
>
>
> Regards
>
> TK
>
>
>
> From: erry321 <erry321@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 27, 2012 9:53 AM
> Subject: [DynoMotion] MPG example
>
>
>
>
>
> Hello
>
> I am new to the kflop board.
> Going to retrofit the mill using one and would like to have MPG's installed
> to be able to use machine as manual till I have got figured out all the
> tricks related to g-code and cnc machining.
> I have been looking at the C examples for the MPG.
> Just one, probably stupid question:
> Why the coefficient for X1 is 1.0, for X10 is 10.0 but for X100 is 75.0?
> Did I miss something?
>
> Best regards,
> Alexey
> |
|
| Group: DynoMotion |
Message: 4678 |
From: Alexey Volkov |
Date: 4/26/2012 |
| Subject: Re: MPG example |
Yes, yes, yes!!!
Sent from my iPhone
I like how you guys think. I'm on the same track here.
Currently I'm working on a Java based product that is supposed to replace the KMotionCNC software. The software will be an eclipse based products enabling others to write their own plugins for whatever they need for their machines.
My progress so far is that the GCodeInterpreter has been ported to execute on Mac OS X compiled as a native shared library. It is compiled and linked with g++ so I don't se any problem with linux ports.
The ftd2xxj project (a JNI interface for ft2dxx native drivers) enables the java program to communicate with my KFLOP.
The GCodeInterpreter is currently only sending the commands to console. But I'm not far away from hooking it up with my Java program that will send the commands to the KFLOP.
The plan is to make my own wrapper for the ftd2xx drivers that will communicating with sockets. That way the application using the drivers can be used by software written in any language. In my case Java.
Future plans is to make a KFLOP server that runs on a Raspberry PI (if possible). Then it actually might be possible to use HTML as GUI and connect to the server with web sockets.
Regards Pär Hansson
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
>
>
> Java in and of itself is not a GUI tool. I'd also argue that you cannot
> get any more ubiquitous than HTML for a GUI as it is used on everything from
> PC's/mobile devices and even toasters. ;)
>
>
>
> C++ seems like the right tool for the cross platform job to me, but any port
> would be really cool.
>
>
>
> Plus there are several suitable GUI toolkits for java(netbeans, etc.) so I'm
> sure it would work out well.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of Alexey Volkov
> Sent: Monday, February 27, 2012 8:28 PM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> I would more look in Java direction for GUI, as a true cross-platform
> solution.
>
>
>
> Best regards,
>
> Alexey
>
> On Mon, Feb 27, 2012 at 5:15 PM, Brad Murry <bradodarb@...> wrote:
>
>
>
>
>
> I am a Microsoft junkie for sure, but a cross platform DynoMotion API
> sounds very interesting. Especially with an HTML5 GUI linked to it with
> websockets for near-native performance.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of Tom Kerekes
> Sent: Monday, February 27, 2012 5:35 PM
> To: DynoMotion@yahoogroups.com
>
>
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Hi Alexey,
>
>
>
> Yes it would be great to have KMotionCNC as a cross platform application.
>
>
>
> I think KMotionCNC+KFLOP+MSWindows is actually a lower cost solution
> compared to Mach3+SS+MSWindows.
>
>
>
> Regards
>
> TK
>
>
>
> From: Alexey Volkov <erry321@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 27, 2012 4:10 PM
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Thanks for the links, Tom
>
>
>
> Regarding the EMC: it does make sence to have G-Code interpreter and GUI
> platform independent and USB board like K-Flop as a motion control board,
> IMHO.
>
> Or at least to have KMotionCNC as cross-platform application, if possible.
> Otherwise the real price of the KFlop board goes up for the price of the OS
> you have to buy.
>
> KFlop is already in the top "hobby segment" price range, compared to cheap
> solutions like Mach3 + LPT (Slow and legacy) or Smoothstepper (have died
> already?).
>
> Ideally, it would be nice to have a standalone system able to get the g-code
> from any available source directly or from the flash memory card.
>
> Did anybody tried to transfer the g-code interpreter and the trajectory
> planner into the Kflop flash memory and run it internally, using the usb as
> a g-code feed only?
>
>
>
> Best regards,
>
> Alexey
>
>
>
>
>
> On Mon, Feb 27, 2012 at 3:55 PM, Tom Kerekes <tk@...> wrote:
>
>
>
> Hi Alexey,
>
>
>
> Yes in certain Applications, Languages, Platforms it is easy to send strings
> to serial devices, so in those cases it makes it easy to send simple
> commands to KFLOP.
>
>
>
> The Console Commands are described here:
>
>
>
> http://www.dynomotion.com/Help/CmdsCategory.htm
>
>
>
> The overview of the C++ libraries is shown here:
>
>
>
> http://www.dynomotion.com/Help/LibrariesFlowDiagram.PNG
>
>
>
> Some of the Library functions are described here (but mainly you will need
> to look at the examples):
>
>
>
> http://www.dynomotion.com/Help/KMotionDLLDriver/KMotionDLL.htm
>
>
>
> The .NET wrapper library probably has the best description of the library's
> capabilities:
>
>
>
> http://www.dynomotion.com/KMotion_dotNet/Docs/Help/KMotion.Net.chm
>
> (note: you will likely need to save this file, right click properties,
> select "unblock", to open this file.
>
>
>
>
>
>
>
> Regarding EMC2: its not really clear how much that would make sense. The
> main design goal of EMC2 is to do the real-time control in the PC. The main
> design goal with KFLOP is to remove all the real-time control from the PC.
>
>
>
> Regards
>
> TK
>
>
>
>
>
>
>
> From: Alexey Volkov <erry321@...>
> To: DynoMotion@yahoogroups.com
>
> Sent: Monday, February 27, 2012 3:18 PM
>
>
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Thanks a lot, Tom!
>
>
>
> So, generally speaking, you use standard FTDI driver to simulate the COM
> port and talk to the KFLOP directly.
>
> Where I can find the information regarding the ASCII console commands and
> open source C++ libraries you mention above?
> I am not a professional programmer but I have done some programming, PC and
> embedded systems, hope I would eventually figure out how all that stuff
> works.
>
> Meanwhile, I would try to use VM with the KmotionCNC, thanks for the
> suggestions.
>
>
>
> By the way, did anybody tried to combine EMC2 with your board?
>
>
>
> Best regards,
>
> Alexey
>
> On Mon, Feb 27, 2012 at 3:05 PM, Tom Kerekes <tk@...> wrote:
>
>
>
> Hi Alexey,
>
>
>
> Regarding:
>
>
>
> #1 - I'm not a machinist and I'm not sure I understand your question. But
> the tool table is not really for any optimization. I think the basic idea
> is that GCode can be generated and then if a tool breaks or needs to be
> changed a new tool can be installed with a slightly different diameter and
> length and then the same GCode can still be used.
>
>
>
> #2 - Yes the PC-KFLOP communication protocol is open. All the communication
> between the PC and KFLOP consists of ASCII Console Script Commands. You can
> send raw Console commands directly to KFLOP to control everything. But to
> operate in this mode you must do most everything yourself - Trajectory
> Planning, buffer management, etc... We have C++ libraries that run on the
> PC that operate on a higher level and allow you to just specify GCode to
> execute, or a Coordinated Motion Path you would like, and the libraries will
> handle all the Trajectory Planning and buffer management for you. These C++
> libraries are all open as well. Unfortunately they contain some Microsoft
> Library References (MFC, CString, etc...) which make them incompatible with
> other platforms.
>
>
>
> We use an FTDI USB device on our board. FTDI provides USB Drivers for many
> platforms including Linux. They also offer Virtual Com Port Drivers which
> makes it easy to have any application that can talk to a serial port send
> Console commands to KFLOP. There are Users who use KFLOP under Linux in
> this manner.
>
>
>
> We have also found that our Applications and libraries run in Linux under
> Wine with the proper FTDI Driver loaded. Even Mach3 runs in Wine under
> Linux with KFLOP. There are a few quirks on connecting and diconnecting the
> device, and some minor GUI issues that would need to be resolved to make a
> releasable product, but running GCode, Jogging, Status, and so forth all
> seems to work.
>
>
>
> Regards
>
> TK
>
>
>
> From: Alexey Volkov <erry321@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 27, 2012 2:22 PM
> Subject: Re: [DynoMotion] MPG example
>
>
>
>
>
> Thanks, Tom
>
>
>
> Just some more question:
>
>
>
> 1. Standard g-code does not have the tool definitions except the offsets,
> so, as I got it, I have to prepare the g-code in the CAM system according to
> the tools I using and the actual mill setup. (The g-code is optimized and
> specified to the mill).
>
> Why KmotionCNC has tool configuration? Just for someone who do not use CAM's
> and does the g-code programming manually? What is better way? (I mean do
> give the CAM to decide the tool path or to use KmotionCNC trajectory planner
> to optimize it for KFlop?)
>
> 2. Is it any "open" information on KFlop - PC communication protocol, so I
> can create custom control software (mostly to change the platform, I would
> prefer to do not use Windows based system). Did anybody try to port
> KMotionCNC to Linux, Mac OSX? As far as KMotion is just GUI, it should not
> be so difficult.
>
> Best regards,
>
> Alexey
>
> On Mon, Feb 27, 2012 at 2:04 PM, Tom Kerekes <tk@...> wrote:
>
>
>
> Hi Alexey,
>
>
>
> No you didn't miss anything that should really be 100.0 or the switch input
> should be renamed to be labled X75. I suspect 100X was a bit too fast for
> one particular machine so the step size was reduced a bit. The selector
> inputs should probably be named SpeedA, SpeedB, SpeedC, SpeedD. Then all
> that has to match is the software factors and the lables on the selector
> switch.
>
>
>
> Regards
>
> TK
>
>
>
> From: erry321 <erry321@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 27, 2012 9:53 AM
> Subject: [DynoMotion] MPG example
>
>
>
>
>
> Hello
>
> I am new to the kflop board.
> Going to retrofit the mill using one and would like to have MPG's installed
> to be able to use machine as manual till I have got figured out all the
> tricks related to g-code and cnc machining.
> I have been looking at the C examples for the MPG.
> Just one, probably stupid question:
> Why the coefficient for X1 is 1.0, for X10 is 10.0 but for X100 is 75.0?
> Did I miss something?
>
> Best regards,
> Alexey
>
|
|
| | | | | | | | | | | | | |
